========================================================================= INFO-ATARI16 Digest Wed, 18 Apr 90 Volume 90 : Issue 458 Today's Topics: Acc DTA Malloc AES FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!! Gemini 1.1 Docs in English Help needed with Protobt (XBIOS $12) (2 msgs) INFO-ATARI16 Digest V90 #454 in search of a FAST GIF viewer Omega for ST? Second request for CX80 Trackball mod information. UUDecode (2 msgs) ---------------------------------------------------------------------- Date: 18 Apr 90 14:27:47 GMT From: zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!imada!micro@tut.cis.ohio-state. edu (Claus Pedersen) Subject: Acc DTA Malloc AES Message-ID: <734@imada.dk> Dear Atarians; I am have here the extract of the anwsers to my questions concerning ACCs, the DTA and malloc: - 'fsel_input' can be used without setting the DTA. - the size of a file can be found by searching to the end of the file. - you can use the 'Fsfirst'/'Fsnext' from Accs, by saving the old DTA, and then setting your own. Please read letter two... - 'Malloc' can't be used from Accs as they are *second class* processes, mainly because they don't have a base page. This is also the reason why 'Pexec' is rather *unstable* from accs. Please read letter one... The two letters following, are answers to : sgstree@relay.EU.net (Samuel Streeper) both have been send during the easter, but I keep getting a "User unknown", when I try to send them. Programs have been tested on my MEGA2 w. tos1.4, my brothers STE w. tos1.6 and my girlfriends MEGA1 w. german tos1.2. (I don't have access to an Atari with tos1.0). ************************* LETTER ONE *************************** Thank you for answering my questions. I really need to malloc, as I am making a text editor. It is not really an editor yet, which is why I call it "more". I have not implemented *all* features of the famous "more" - really it can only open and view files - no fancy stuff at all. The only way to avoid malloc is to make a combined ramdisc and editor. This will of course not solve the problem of having a very large chunk of unused memory, but it will be more easy to justify (as many people are using a large fixed size ramdisc, for various reasons, of which the least is not the lack of a fixed-multi- megabyte-device. I have experimented with the 'active_process'-pointer, and I have found that it can be used to get the ownership of malloced memory, and to get a private DTA. When using malloc or Fsfirst/Fsnext simply let the 'active_process' point to the basepage of the acc. It works and why shouldn't it? - Malloc uses the pointer to stamp the memory blocks, and Basepage allways points to the DTA of choice. _It really works with both 'Fsfirst' and 'Malloc'._ I use the following code : /*****************************************/ /* Hacks to do what allready is possible */ /*****************************************/ extern SYSHDR *Sysbase; extern BASPAG *_BasPag; BASPAG *OldPD; void UseMyBase(void) ? OldPD = *Sysbase->_run; *Sysbase->_run = _BasPag; ? void UseOldBase(void) ? *Sysbase->_run = OldPD; ? It is very simple to use, the DTA has to be set one time only: main() ? ... UseMyBase(); Fsetdta(&FileInfo); UseOldBase(); ... ? And here is the interesting part of the 'open file' : if (FileSelect(TextPath)) ? UseMyBase(); Err = Fsfirst(TextPath, 0); ... (no AES calls) ... Text.Document = Malloc( FileInfo.d_length + Epsilon ); UseOldBase(); ... ? I didn't want to reenvent the wheel, but I think I just have... -don't tell me nobody have ever tried to do this before. There will be problems if the dispatcher ever runs on a different scheme (say time sliced). If that ever happens this hack will be in deep trouble (and so will your suggestion about saving DTA, setting, using and restoring it) old = Fgetdta(); Fsetdta(new); ... do funny things ... /* if the dispatcher ever runs here, there will be trouble - the sky will spit fire, the earth will open and file searches will fail... */ Fsetdta(old); However, notice that if the dispatcher was common to both the AES and GEMDOS there would be no trouble (as there is now). The dispatcher only needs to update the 'Active_Process' (of GEMDOS fame), so that it _always_ points to the basepage of the running process. As to my experiment with AC_CLOSE : > case AC_CLOSE: > Cconws("acc closed"); > Cconin(); > form_alert(1,"[1][|Closed][OK]"); > break; What happened was that "acc closed" appeared on the screen before the application had terminated!, then the desktop was opened (lots of AES calls), and then the alert box "closed". It appears that there is a fixed number of 'free' AES calls, just after the application is started, and that the dispatcher runs before AES calls. More interesting it seems that some programs uses the AES _after_ 'Pterm'! - handy to close windows and restore the desktree - with the 'etv_term' vektor I guess. This has the added bonus that windows are closed and the desktree gets restored - even when the program terminates abnormal (with those cute bombs). Please let me hear any comments -micro@imada.dk (Klaus Pedersen). ************************* LETTER TWO *************************** What a bummer, Sorry. In my last letter I wrote : > More interesting it seems that some programs uses the AES >_after_ 'Pterm'! What a bummer - as it is 'appl_exit' that sends the 'AC_CLOSE' message, the only way to get the acc to get the message, before a new program starts, is to make AES calls _after_ the 'appl_exit'... It seems that I am not the only one making bummers. Sorry, but I was carried away by the perspectives of having a 'etv_term' program doing all the cleaning up : > - handy to close windows and restore the desktree - > ... This has the added bonus that windows are closed and >the desktree gets restored - even when the program terminates >abnormal ... In fact I have tried to have the exit code in the 'etv_term' chain, using some code looking like this : extern void Set_etv_term(void *a); extern void (*Old_etv_term)(void); void Close( void ) ?int wind; wind = Text.WindId; graf_mouse(M_OFF,0); wind_close(wind); wind_delete(wind); menu_bar(M_tree, ME_HIDE); graf_mouse(M_ON, 0); rsrc_free(); v_clsvwk(handle); appl_exit(); (*Old_etv_term)(); ? main() ? Set_etv_term(Close); Get_sysbase(); ... ? And some assembly to do the dirty work, please note that I use Turbo C, which uses the registers to pass parameters, when nothing else has been said (An to pointers, Dn to ints, longs) : include "tos.s" export Get_sysbase, Sysbase, Set_etv_term, Old_etv_term TEXT ****** Set Etv_term pointer ****** Set_etv_term: MOVE.L A0, temp PEA get_etv_term XBIOS supexec, 6; Call Xbios funktion and dealloc 6 bytes RTS get_etv_term: MOVE.L etv_term, Old_etv_term MOVE.L temp, etv_term RTS ****** Get SysBase ****** Get_sysbase: PEA get_sys XBIOS supexec, 6 RTS get_sys: MOVE.L _sysbase, Sysbase RTS BSS temp: DS.L 1 Sysbase: DS.L 1 Old_etv_term: DS.L 1 But the test program bombs out, not these assembly funktions, they are working. The function 'Close' is called and closes the window, and then Illustrates the drawback of having code in the 'etv_term' - it bombs (two bombs), and the bomb routine makes an 'Pterm(-1)' in TOS1.4 that is, the 'Pterm' calls the 'etv_term' vektor, where the 'Close' code are, which bombs and so it goes on. Any suggestions ? -micro@imada.dk (Klaus Pedersen). ------------------------------ Date: 18 Apr 90 17:25:31 GMT From: earthquake.Berkeley.EDU!kawakami@ucbvax.Berkeley.EDU (John Kawakami) Subject: FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!! Message-ID: <35590@ucbvax.BERKELEY.EDU> In article <3143@umbc3.UMBC.EDU> petey@umbc5.umbc.edu () writes: > >Hey everyone: >This one to the ASSEMBLY HACKS out there. > >Has anyone written a sprite routine that can beat the Line-A routines >is the ST? Without using multiple copies of the sprite offset by 1 pixel >so that it can be put onto non-byte boundries??? > >It seems that since the line-a routines are in rom and can be READ faster >therefor executed faster that this is not possible. But ive heard people >claim they can do it. > >I would like some psuedo-code or code to do this. >Code for a monochrome monitor ( 1 BIT PLANE ) would be perferred, just so >we dont have to mess with the strange way the ST uses 4 bitplanes. > >I wrote a routine that put the sprite to the screen byte by byte shifting >each byte as required. The line-a routine was still about 3 times faster >and my routine only used adds, shifts, and moves. > >well, has ANYONE out there done this? I have not done any ST assembly hacking, but one way to speed up writes of bitmaps is to pre-shift the bitmap and then write it. For sprites, which are presumably all the same size or of several fixed sizes, you can just pre-shift the sprite (8 times once for each bit) and use the lower three bits as an index into this array of pre-shifted bitmaps. (GHOD that's turgid) In simple terms that even I would understand: instead of taking the bitmap, shifting it, and writing it; have it set up so you have to "register" the bitmap, and return a handle, then pre-shift so you don't have to shift "on the fly", and handle sprite calls by taking the x,y, and handle. End result: you need to do a bit more pre-processing, but less time is spent writing to the screen. Also, you use more memory, but so what! John Kawakami kawakami@earthquake.berkeley.edu ucbvax!earthquake.berkeley.edu!kawakami take-a-right-up-the-hill-then-a-left-on-leroy ------------------------------ Date: Wed, 18 Apr 90 11:55:13 MSZ From: ONM65%DMSWWU1A.BITNET@CUNYVM.CUNY.EDU (Operator Stefan) Subject: Gemini 1.1 Docs in English Message-ID: <9004180855.AA24660@hugin.dmswwu-ether> In article <776@ncs.dnd.ca> R. J. Balkwill writes: > I have translated the docs for Gemini 1.1 (Gemini, Venus and Mupfel) > from German into English but will not post them unless: > > a. There is interest > > b. A few days go by without objection by the authors of Gemini. It is very kind of You to translate the documents. But we have made an english version of the programs to which the docs should refer. Also, we found someone in the Netherlands who is now translating the docs. If you don't mind, please send me the docs, so I can change the names of the dialogs and menu entries. When we got the english docs, we will beam an english version of Gemini 1.1 to the world immediately. _____________________________________________________ | Stefan Eissing +----+ \|# | Dorfbauerschaft 7, D-4419 Laer-Holthausen | OK | |# | "Author of Venus@Gemini" +----+ |# |_____________________________________________________|# ####################################################### ------------------------------ Date: 18 Apr 90 10:56:05 GMT From: mcsun!ukc!harrier.ukc.ac.uk!gos.ukc.ac.uk!shc1@uunet.uu.net (S.H.Cogheil) Subject: Help needed with Protobt (XBIOS $12) Message-ID: <2928@gos.ukc.ac.uk> I am currently trying to write a boot-sector that will make the floppy access time 6ms. However whenever I use the Protobt fucntion I get nothing written to my floppy Will someone please explain how this Bl**dy function works ! Sam ------------------------------ Date: 18 Apr 90 15:33:30 GMT From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut.cis.ohio-state.edu (Howard Chu) Subject: Help needed with Protobt (XBIOS $12) Message-ID: <11748@stag.math.lsa.umich.edu> In article <2928@gos.ukc.ac.uk> shc1@ukc.ac.uk (S.H.Cogheil) writes: >I am currently trying to write a boot-sector that will make the floppy access time 6ms. >However whenever I use the Protobt fucntion I get nothing written to my floppy > >Will someone please explain how this Bl**dy function works ! > >Sam Protobt merely generates usable data in the memory buffer you pass it. You then have to call Flopwrt yourself to get the boot sector written onto the disk. Btw, how is one supposed to generate a correct checksum for the boot sector? My impression from reading the description of Protobt is that it completely overwrites the contents of the buffer you pass it, so you have to make any changes (adding executable code, altering the parameter block, etc.) after the call, and most probably ending up with an invalid checksum. Am I missing something obvious here? -- -- Howard Chu @ University of Michigan ------------------------------ Date: Wed, 18 Apr 90 10:15 EST From: SNARK%NRCBSP.NRC.CA@VM.NRC.CA Subject: INFO-ATARI16 Digest V90 #454 Please unsubscribe (time to go home) snark@nrcbsp.nrc.ca ------------------------------ Date: 18 Apr 90 14:46:34 GMT From: orion.oac.uci.edu!uci-ics!gateway@ucsd.edu (Wayne Ngai) Subject: in search of a FAST GIF viewer Message-ID: <262C7DCA.24047@paris.ics.uci.edu> Does anyone has a fast GIF picture viewer for Atari?? If so, please mail me a copy of it. I used GIFSHOW, but it's just too slow. Any of you familiar with CSHOW gif viewer for IBM?? Anything of that class would be great!! Wayne wngai@paris.ics.uci.edu ------------------------------ Date: 18 Apr 90 17:40:42 GMT From: mailrus!news-server.csri.toronto.edu!utgpu!watserv1!ria!uwovax!7103_2622@tut.ci s.ohio-state.edu (Eric Smith) Subject: Omega for ST? Message-ID: <5765.262c6e5a@uwovax.uwo.ca> In article <922@ruunsa.fys.ruu.nl>, muts@fysae.ruu.nl (Peter Mutsaers) writes: > I would like to know if someone has ported the game of omega to the ST. > If so, I would like to hear from it. I am trying to translate it myself, > but have some problems. I compiled an older version of it with the gcc. Very few changes were necessary. However, it was a bit slow (using 16 bit integers would help -- perhaps the MS-DOS version of omega would be a better starting point). It was also quite buggy; again, the fact that it was an older version may have something to do with this. At any rate, I can strongly recommend using the gcc for doing any ports of unix software; the library has a lot of commonly used unix functions, including a non-multitasking fork(). -- Eric R. Smith email: Dept. of Mathematics ERSMITH@uwovax.uwo.ca University of Western Ontario ERSMITH@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638 ------------------------------ Date: Wed, 18 Apr 90 12:51:24 EDT From: longj@LONEX.RADC.AF.MIL (Jeffrey K. Long) Subject: Second request for CX80 Trackball mod information. Message-ID: <9004181651.AA01076@lonex.radc.af.mil> This is a second plea for info on modifying an ATARI CX80 (thats eight-zero) trakball to work as a mouse on the ST. I have an article for the CX22, but they seem to be totally different beasts! Surely someone must have done this mod before !!?? (and I'm sorry for calling you all Sirley :-) ) ------------------------------ Date: 18 Apr 90 12:44:15 GMT From: cs.dal.ca!silvert@uunet.uu.net (Bill Silvert) Subject: UUDecode Message-ID: <1990Apr18.124415.19867@cs.dal.ca> In article <9004180507.AA14277@fsucs.cs.fsu.edu> boyd@nu.cs.fsu.edu (Mickey Boyd) writes: >In article <2927@gos.ukc.ac.uk>, anw1@ukc.ac.uk (A.N.Walkeden) writes: >>I have found a piece of PD software I would like, and have FTP'd it to >>my machine, where I find it is over 700KBytes in size. >>Now when I UUDecode this file it produces another output file of similar >>magnitude, thus there is not enough room for it on a 3.5" disk. > >What is the name of the file? I have never come across that problem, but >one possible solution (temporary) would be to arc the file on the host >machine, and then run it from arc on your ST. I have heard this is >possible, but I have never done it. Why not just decode it on the host machine? If it doesn't have uudecode, then just port uud, for which portable source coude is readily available (from me, for example). -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!?uunet|watmath?!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca ------------------------------ Date: 18 Apr 90 16:49:08 GMT From: samsung!uakari.primate.wisc.edu!larry!gaudi!billm@uunet.uu.net (Bill Mills) Subject: UUDecode Message-ID: <1990Apr18.164908.5831@gaudi.CSUFresno.EDU> The best way that I have found to break up large arcs that I uuencode/ decode (since I don't have a hard disk) is to ifng (oops) find someone with a hard disk. I have uudecoded files that were too big to fit on a floppy, then downloaded them to an IBM PC (ugh) at work where I de-arc them, and then tranfer the files to floppy to use on my ST. SInce ARC is the same on MS-DOS as it is for the ST, it makes it that much easier to find someone with a hard disk (more people with PC systems). Hope that helps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -Bill Mills Bill@csufres.csufresno.edu billm@gaudi.csufresno.edu ------------------------------ End of INFO-ATARI16 Digest V90 Issue #458 *****************************************